Notes

• I'm using on @Native annotations to load all the ffi symbols. Previously this worked because I loaded the dylib into the executable first, then relied on the @Native fallback behavior to load the symbols from the exe. Now I'm explicitly setting the asset name to the built dylib, which appears to disable that fallback behavior. But all the core ObjC runtime symbols (eg objc_msgSend) are linked into the exe, not the dylib. So I had to split the C bindings into a set that loads from the dylib, and a set that loads from the exe. There are now 3 sets of ffigen created bindings: the objective C bindings (loads from the dylib), the bindings for my C code (loads from the dylib), and the bindings for the built in ObjC runtime's C code (loads from the exe).
• Similarly, I had an issue where the global variables exposed by the ObjC bindings were failing to load. So I moved them to the C runtime bindings so they'd be loaded from the exe. This exposed them as a raw Pointer<ObjCObject>, so I had to manually wrap them in NSStrings in globals.dart. I tried splitting the ObjC bindings like I split the C bindings, but this caused all sorts of other problems.
• ffigen has a dev dep on package:objective_c for testing. All the ObjC tests are disabled on linux and windows, but afaik there's no way of avoiding pulling in the dependency on those platforms. So I had to modify package:objective_c's build script to no-op on those platforms. Seems like a sub-optimal solution.